Peer applications trust center

ABSTRACT

Concepts and technologies are disclosed herein for a peer applications trust center. A trust client can execute on a client computer and a trust service can execute on a server computer to provide the peer applications trust center. The trust client or trust server can register applications. During registration, the trust server or the trust client can generate a public key or other identifier for identifying the registered application. If another application requests access to the registered application, the trust server or the trust client can determine if the request specifies a registered application by name. If the requestor is granted access to the application, the requestor can be issued a token. Tokens can be revoked, updated, replaced, or renewed for various purposes.

CROSS-REFERENCE TO RELATED APPLICATION

This application is a continuation of and claims priority to U.S. patentapplication Ser. No. 13/448,456, entitled “Peer Applications TrustCenter,” filed on Apr. 17, 2012, now U.S. Pat. No. 8,990,913, which isincorporated herein by reference in its entirety.

BACKGROUND

Businesses and consumers often use applications to manage or interactwith data from various sources. In some business scenarios, one or moreapplications may be developed to control or manage data from varioussystems or other sources. These applications sometimes are created byprogrammers employed by the businesses. In some instances, theseapplications can be created by OEMs. These and other applicationssometimes are developed over time and/or extensive effort to provide arich experience for users.

In some circumstances, various applications that are valuable orimportant for business operations may become outdated and/or otherwiseincompatible with future applications or other systems used by abusiness. For example, businesses may want some applications tocommunicate with one another to provide particular functionality, butmay be unable to do so without writing and implementing new code and/orversions of the software.

Similarly, some settings or configurations associated with applicationsmay be protected or otherwise inaccessible to users and/or applications.Enabling applications to communicate with one another may requirecreation of a new application or a new application programming interface(“API”) to support these and other types of communications between theapplications. Still further, as operating systems evolve and/or areadopted by some application users, APIs and/or applicationfunctionality, configurations, and/or settings may be inaccessibleand/or unusable or incompatible with applications executing on theevolved or newly-adopted operating systems.

SUMMARY

The present disclosure is directed to a peer applications trust center.The peer applications trust center can include a trust client executingon a client computer and a trust service executing on a server computerin communication with the trust client. The trust client can beconfigured to register applications and/or to submit information to thetrust server for registration of the applications. During registrationof the applications, the trust server or the trust client can generate apublic key or other identifier associated with the application. Ifanother application requests access to the registered application, thetrust server or the trust client can determine if the request specifiesa registered application by name.

If the request specifies a registered application by a correct and/orcurrent name, the trust server can be configured to grant access to therequestor. The requestor can be issued a token for accessing theapplication. The tokens can be assigned a life or a time period forwhich the tokens will be valid. If the life or time period expires, thetokens can be revoked, new tokens can be issued, and a trustrelationship between the requestor and the application can bereestablished using a new token. As such, trust relationships can bekept up to date, if desired.

According to one aspect of the concepts and technologies disclosedherein, a method is disclosed. The method can include registering, at atrust service, an application. Registering the application can includegenerating an identifier associated with the application. The methodalso can include receiving a request to establish a trust relationshipbetween a requestor associated with the request and the application anddetermining if the trust relationship is to be established. The methodalso can include issuing a token to the requestor in response todetermining that the trust relationship is to be established and issuingan error code, in response to determining that the trust relationship isnot to be established.

In some embodiments, the method further includes receiving anapplication access request from the requestor, the application accessrequest comprising the identifier, and challenging the requestor, basedupon the identifier, to determine if the access request is to begranted. The identifier can include a globally unique identifier. Therequest to establish the trust relationship can include a nameassociated with the application. In some embodiments, determining if thetrust relationship is to be established can include examining the name,determining if the name includes a recognized identifier associated withthe application, and determining that the trust relationship is to beestablished, if the name includes the recognized identifier. In someembodiments, issuing the token can include determining a time period forwhich the token is to be valid, specifying the life of the token, thelife of the token including data indicating the time period, and issuingthe token with the specified life of the token.

The method also can include determining if the token is expired, andissuing a new token, in response to determining that the token isexpired. The method also can include determining that a new version ofthe token is available, revoking the token, and issuing the new versionof the token. In some embodiments, the application includes anapplication executing on a first application server, and the requestorincludes a further application executing on a further applicationserver. The error code can specify an error associated with the request.The error code also can include an action code, which can specify anaction to be taken in response to determining that the trustrelationship is not to be established.

According to another aspect of the concepts and technologies disclosedherein, another method is disclosed. The method can include registering,at a trust service in communication with an application server, anapplication executing on the application server. The method also caninclude generating a globally unique identifier associated with theapplication and receiving, from a requestor in communication with thetrust service, a request to establish a trust relationship between therequestor and the application executed by the application server. Therequest to establish the trust relationship can include a nameassociated with the application. The method also can include determiningif the trust relationship is to be established based, at leastpartially, upon the name included in the request, issuing, to therequestor, a token, in response to determining that the trustrelationship is to be established, and issuing an error code, inresponse to determining that the trust relationship is not to beestablished.

In some embodiments, the requestor is a further application executed bya further application server. The method also can include receiving anapplication access request from the requestor, the application accessrequest including the identifier; and challenging the requestor, basedupon the identifier, to determine if the access request is to begranted. In some embodiments, determining if the trust relationship isto be established includes examining the name, determining if the nameincludes a recognized identifier associated with the application, anddetermining that the trust relationship is to be established, if thename includes the recognized identifier. In some embodiments, the errorcode specifies an action to be taken in response to determining that thetrust relationship is not to be established.

According to yet another aspect, a computer storage medium is disclosed.The computer storage medium can have computer-executable instructionsstored thereon that, when executed by a server computer, cause theserver computer to execute a method. The method can include registering,at the computer, an application executing on an application server incommunication with the computer and generating an identifier associatedwith the application. The method also can include receiving, from arequestor in communication with the computer, a request to establish atrust relationship between the requestor and the application executed bythe application server. The request to establish the trust relationshipcan include a name associated with the application. The method also caninclude determining if the trust relationship is to be establishedbased, at least partially, upon the name included in the request,issuing, to the requestor, a token, in response to determining that thetrust relationship is to be established, and issuing an error code, inresponse to determining that the trust relationship is not to beestablished.

In some embodiments, the requestor includes a further applicationexecuted by a further application server, and the identifier includes aglobally unique identifier. The method also can include receiving anapplication access request from the requestor, the application accessrequest including the identifier; and challenging the requestor, basedupon the identifier, to determine if the access request is to begranted. In some embodiments, determining if the trust relationship isto be established can include examining the name, determining if thename includes a recognized identifier associated with the application,and determining that the trust relationship is to be established, if thename includes the recognized identifier.

Other systems, methods, and/or computer program products according toembodiments will be or become apparent to one with skill in the art uponreview of the following drawings and detailed description. It isintended that all such additional systems, methods, and/or computerprogram products be included within this description, be within thescope of this disclosure, and be protected by the accompanying claims.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a system diagram illustrating an illustrative operatingenvironment for the various embodiments disclosed herein.

FIG. 2 is a flow diagram showing aspects of a method for establishing atrust relationship between applications, according to an illustrativeembodiment.

FIG. 3 is a flow diagram showing aspects of a method for revoking andrenewing a trust relationship between applications, according to anotherillustrative embodiment.

FIG. 4 is a flow diagram showing aspects of a method for renewing atrust relationship between applications, according to anotherillustrative embodiment.

FIG. 5 schematically illustrates a network, according to an illustrativeembodiment.

FIG. 6 is a block diagram illustrating an example computer systemconfigured to manage trust relationships between applications, accordingto some illustrative embodiments.

DETAILED DESCRIPTION

The following detailed description is directed to a peer applicationstrust center, which can be provided by a trust client executing on aclient computer and a trust service executing on a server computer incommunication with the trust client. The trust client can be configuredto register applications executing on application servers incommunication with the trust client and/or the client computer, and/orto submit information to the trust server for registration of theapplications. During registration of the applications, the trust serveror the trust client can generate a public key or other identifierassociated with the application. In some instances, the public key orother identifier can include a globally unique identifier. If anotherapplication requests access to the registered application, the trustserver or the trust client can determine if the request specifies aregistered application by name. If the requestor is granted access tothe application, the requestor can be issued a token. The tokens can beassigned a life or a time period for which the tokens will be valid. Ifthe life or time period expires, the tokens can be revoked, new tokenscan be issued, and a trust relationship between the requestor and theapplication can be reestablished using a new token. The tokens also canbe revoked or replaced for other purposes. As such, trust relationshipscan be kept up to date, if desired.

While the subject matter described herein is presented in the generalcontext of program modules that execute in conjunction with theexecution of an operating system and application programs on a computersystem, those skilled in the art will recognize that otherimplementations may be performed in combination with other types ofprogram modules. Generally, program modules include routines, programs,components, data structures, and other types of structures that performparticular tasks or implement particular abstract data types. Moreover,those skilled in the art will appreciate that the subject matterdescribed herein may be practiced with other computer systemconfigurations, including hand-held devices, multiprocessor systems,microprocessor-based or programmable consumer electronics,minicomputers, mainframe computers, and the like.

Referring now to FIG. 1, aspects of an operating environment 100 forvarious embodiments of the concepts and technologies disclosed hereinfor a verification service for providing data delivery with senderverification will be described, according to an illustrative embodiment.The operating environment 100 shown in FIG. 1 includes a client computer102 operating in communication with and/or as part of a communicationsnetwork (“network”) 104. According to various embodiments, thefunctionality of the client computer 102 may be provided by one or moreserver computers, desktop computers, mobile telephones, smart phones,laptop computers, set-top boxes, other computing systems, and the like.Furthermore, it should be understood that the functionality of theclient computer 102 can be provided by a single device, by two similardevices, and/or by two or more dissimilar devices. For purposes ofdescribing the concepts and technologies disclosed herein, the clientcomputer 102 is described herein as a personal computer. It should beunderstood that this embodiment is illustrative, and should not beconstrued as being limiting in any way.

The client computer 102 can execute an operating system 106 and one ormore application programs such as, for example, a trust clientapplication or module (“trust client”) 108. The operating system 106 isa computer program for controlling the operation of the client computer102. The trust client 108 is an executable program configured to executeon top of the operating system 106 to provide various functionsdescribed herein for establishing and/or managing trust relationshipsbetween applications. Although the trust client 108 and the operatingsystem 106 are illustrated as separate entities executed by the clientcomputer 102, it should be understood that in some embodiments, thefunctionality described herein with respect to the trust client 108 isprovided by the operating system 106. In other words, the trust client108 and/or the functionality associated therewith can be provided by theoperating system 106. In some embodiments, including the functionalityof the trust client 108 within the operating system 106 can enhancesecurity of the trust client 108 relative to the illustrated embodimentswherein the trust client 108 is an application executed on top of theoperating system 106. It should be understood that these embodiments areillustrative, and should not be construed as being limiting in any way.

As used herein, the phrase “trust relationship” and variants thereof canbe used to refer to a relationship between one or more applications orservices. When applications or services share a trust relationship, theapplications or services can expose or share provisioning, configurationinformation, settings, or other application- or service-relatedinformation or data with other applications or servers. As such, theconcepts and technologies disclosed herein for establishing and managingtrust relationships can be used to allow two previously unknown orunrelated applications or services to trust one another and exposeservices and/or information to one another. These and other aspects oftrust relationships are described in more detail below, as are variousconcepts and technologies for establishing, managing, and/or revokingtrust relationships.

Although the trust client 108 is illustrated as a component of theclient computer 102, it should be understood that the trust client 108may be embodied as or in a stand-alone device or component thereofoperating as part of or in communication with the network 104 and/or theclient computer 102. As such, the illustrated embodiment should beunderstood as being illustrative of only some contemplated embodimentsand should not be construed as being limiting in any way.

According to various contemplated embodiments of the concepts andtechnologies disclosed herein, the trust client 108 can be configured asan application or an application programming interface (“API”) thatexecutes on the client computer 102. The trust client 108 can beconfigured to communicate with a trust management application, module,or service (“trust service”) 110. The trust service 110 can be executed,hosted, or otherwise provided by or associated with a server computer112 that operates as a part of, or in communication with, the network104. As will be described in more detail below, the trust service 110can be configured to manage and selectively share application or serviceidentifiers or public keys with requesting applications or services(“requestors”), to issue, update, and/or revoke tokens that can be usedby the requestor to access applications or services, and to controlregistration and/or deregistration of applications or services with thetrust service 110.

According to various embodiments, the trust client 108 and the trustservice 110 can be configured to communicate with one another throughone or more secured communication channels established over a publicdomain associated with the network 104. In some other embodiments, thetrust client 108 and the trust service 110 can communicate usingunsecured communication channels, for example, when the trust client 108and the trust service 110 are hosted by real or virtual resources withina same domain, as well as in scenarios in which the trust client 108 andthe trust service 110 are executed by devices or resources within atrust relationship, as described in more detail below. As such, whencommunications between the trust client 108 and the trust service 110are described herein, it should be understood that such communicationscan be secured and/or unsecured.

As will be explained in more detail below, the trust client 108 and thetrust service 110 can exchange various queries, responses, error codes,keys, tokens, and/or other information or data (collectively illustratedand/or referred to herein as “data”) 114 to provide the functionalitydescribed herein for establishing and managing a trust relationshipbetween applications. In addition to exchanging the data 114, the trustclient 108 and/or the trust service 110 can be configured to store thedata 114 at the client computer 102 and/or the server computer 112,respectively, or to access or store the data 114 in a database or otherdata storage device. The various communications and/or data 114 relatingto the communications are described in more detail below.

The illustrated operating environment 100 can include two or moreapplication servers 116A-B (hereinafter collectively and/or genericallyreferred to as “application servers 116”). The application servers 116can be configured to host and/or execute one or more applications orservices (“applications”) 118A-B (hereinafter collectively and/orgenerically referred to as “applications 118”). According to variousembodiments, the applications 118 can be configured to access the trustclient 108 of the client computer 102 to access functionality of thetrust client 108 for establishing and/or maintaining a trustrelationship between the applications 118. According to variousembodiments, each of the applications 118 can be configured withparticular settings or configurations relevant to respective servicesassociated with the applications 118. As such, the communicationsbetween the trust client 108 and the trust service 110, and/or the data114 exchanged between the trust client 108 and the trust service 110,can relate to queries and responses for requesting or granting accessamong the applications 118, as is explained in more detail herein,particularly with reference to FIGS. 2-4.

According to some embodiments of the concepts and technologies disclosedherein, the trust client 108 can be configured to support registrationof applications 118. The trust client 108 can be configured to assign tothe applications 118, or services associated with the applications 118,a globally unique name for identifying the application 118. The globallyunique name is referred to herein as a “public key.” As will beexplained in more detail below, an application or service (“requestor”)requesting another application or service (“target”), or informationassociated therewith, can submit a query to the trust client 108. Thequery can identify the target application or service by name. The publickey for a particular application 118 can be represented by and/or storedas the data 114.

As mentioned above, the trust client 108 can be configured to receiverequests for the target. According to various embodiments, the requestscan correspond to a query that specifies a requested service orapplication by name. The requests and/or the responses thereto also arerepresented in FIG. 1 as the data 114. If the trust client 108determines that the requested application or service (“target”) exists,the trust client 108 can determine if an up-to-date token that can beused by the requestor to access the target application or service namedin the request. If the trust client 108 determines that no up-to-datetoken is available, the trust client 108 can issue an error code to therequestor indicating one or more errors. The tokens and error codes arealso illustrated in FIG. 1 as the data 114. As such, it can beappreciated that the data 114 illustrated in FIG. 1 can include queries,responses, keys, tokens, and/or error codes. It should be understoodthat this embodiment is illustrative, and should not be construed asbeing limiting in any way.

The trust client 108 can be configured as a trusted entity for anyapplication 118 configured to access the trust client 108. As such, thetrust client 108 also can be configured to invoke trust managementfunctionality with respect to any registered application 118. Thus, thetrust client 108 also can be configured to update, revoke, add, and/orremove tokens associated with the applications 118. Two illustrativemethods for updating tokens are illustrated below with reference toFIGS. 3-4.

In operation, the application 118A can be created and can be configuredto access the trust client 108. Similarly, the application 118B can becreated and can be configured to access the trust client 108. Theapplications 118 can register with the trust client 108. Duringregistration, each of the applications 118 can be assigned globallyunique identifiers that can be stored as public keys by the trust client108. As mentioned above, the public keys can be stored as the data 114.

If the application 118A corresponds to a requestor and the application118B corresponds to a target, the application 118A can submit a requestor the trust client 108. The request can be used by the application 118Ato request access to the application 118B. The requested access caninclude a request to use a service associated with the application 118B,a request for configurations, settings, options, or other informationassociated with the application 118B, and/or a request for otherinformation or functionality associated with the application 118B.

While previous approaches to managing trust between applications mayhave included creating specific APIs and/or other “hooks” for accessinginformation associated with the application 118B, the concepts andtechnologies disclosed herein can provide an operating-system-agnosticapproach for accessing the application 118B. Furthermore, the conceptsand technologies disclosed herein can be used to support interactionsbetween any registered applications 118, regardless of languages,protocols, or other application-specific variables, and/or withoutrequiring specifically-tailored APIs or other specialized accessmechanisms.

The trust client 108 can respond with a trust token (“token”) foraccessing the application 118B, and the requestor can use the token toaccess the application 118B. It can be appreciated, therefore, that theregistration of applications 118 and the issuance of a token to one ormore of the applications 118 can correspond, in some embodiments, to theestablishment of a trust relationship between the applications 118. Aswill be described in more detail herein, the trust client 108 also canbe configured to manage the trust relationship by renewing, revoking,reissuing, and/or otherwise updating the tokens, by deregistering and/orordering self destruction of registered applications, suspendingapplications or ordering applications to suspend execution, and/or totake other actions with respect to trust relationships. As such, thetrust client 108 can be configured to establish and/or manage trustrelationships by issuing and managing tokens and/or by issuing orinvoking various error codes or action codes.

FIG. 1 illustrates one client computer 102, one network 104, one servercomputer 112, and two application servers 116. It should be understood,however, that various implementations of the operating environment 100include multiple client computers 102, multiple networks 104, multipleserver computers 112, and less than two or more than two applicationservers 116. As such, the illustrated embodiment should be understood asbeing illustrative, and should not be construed as being limiting in anyway.

Turning now to FIG. 2, aspects of a method 200 for establishing a trustrelationship between applications will be described in detail, accordingto an illustrative embodiment. It should be understood that theoperations of the methods disclosed herein are not necessarily presentedin any particular order and that performance of some or all of theoperations in an alternative order(s) is possible and is contemplated.The operations have been presented in the demonstrated order for ease ofdescription and illustration. Operations may be added, omitted, and/orperformed simultaneously, without departing from the scope of theappended claims.

It also should be understood that the methods disclosed herein can beended at any time and need not be performed in its entirety. Some or alloperations of the methods, and/or substantially equivalent operations,can be performed by execution of computer-readable instructions includedon a computer storage media, as defined herein. The term“computer-readable instructions,” and variants thereof, as used in thedescription and claims, is used expansively hereinto include routines,applications, application modules, program modules, programs,components, data structures, algorithms, and the like. Computer-readableinstructions can be implemented on various system configurationsincluding single-processor or multiprocessor systems, minicomputers,mainframe computers, personal computers, hand-held computing devices,microprocessor-based, programmable consumer electronics, combinationsthereof, and the like.

Thus, it should be appreciated that the logical operations describedherein are implemented (1) as a sequence of computer implemented acts orprogram modules running on a computing system and/or (2) asinterconnected machine logic circuits or circuit modules within thecomputing system. The implementation is a matter of choice dependent onthe performance and other requirements of the computing system.Accordingly, the logical operations described herein are referred tovariously as states, operations, structural devices, acts, or modules.These states, operations, structural devices, acts, and modules may beimplemented in software, in firmware, in special purpose digital logic,and any combination thereof.

For purposes of illustrating and describing the concepts of the presentdisclosure, the methods disclosed herein are described as beingperformed by the client computer 102 via execution of one or moresoftware modules such as, for example, the trust client 108. It shouldbe understood that additional and/or alternative devices and/or networknodes can provide the functionality described herein via execution ofone or more modules, applications, and/or other software including, butnot limited to, the trust client 108. Furthermore, it can be appreciatedfrom the above description that the trust client 108 can provide thefunctionality described herein via one or more interactions with a trustservice 110. Thus, the illustrated embodiments are illustrative, andshould not be viewed as being limiting in any way.

The method 200 begins at operation 202, wherein the client computer 102can register or complete registration for two or more applications 118.During registration of the applications 118, the client computer 102and/or the trust client 108 executed thereon, can access the trustservice 110 to obtain and/or store public keys associate with theapplications 118. For example, the trust client 108 can query the trustservice 110. The query can include a request for a public key for one ormore of the applications 118, and the trust service 110 can respond tothe query with one or more public keys. As mentioned above, the publickeys can be provided to the client computer 102 as the data 114.According to various embodiments, the public keys can include globallyunique identifiers (“GUIs”) that can be used to uniquely identifyservices associated with the applications 118. Because other forms ofunique identifiers can be used instead of, or in addition to, the GUIsmentioned above, it should be understood that this embodiment isillustrative, and should not be construed as being limiting in any way.

From operation 204, the method 200 proceeds to operation 204, whereinthe client computer 102 receives a request to establish a trustrelationship between two or more of the applications registered inoperation 202. According to various embodiments, the client computer 102can receive the request from one or more of the applications 118. Forpurposes of clarifying the concepts and technologies disclosed herein,the embodiment illustrated in FIG. 2 is described with reference to arequesting application such as the application 118A (hereinafter alsoreferred to as the “requestor” for clarity) and a targeted or requestedapplication or service such as the application 118B (hereinafter alsoreferred to as the “target application” for clarity). The requestor cansubmit the request to the trust client 108 as the data 114.

According to various embodiments, the request received in operation 204can specify a name or other identifier for the target application orother requested service or application. The name or other identifier caninclude a GUI, as mentioned above, or other information for uniquelyidentifying one or more applications 118. The name or other identifiercan be used by the client computer 102 and/or the trust client 108executed thereon to determine if a trust relationship is to beestablished between the requestor and the target application. It shouldbe understood that this embodiment is illustrative, and should not beconstrued as being limiting in any way.

From operation 204, the method 200 proceeds to operation 206, whereinthe client computer 102 can determine if the trust relationship is to beestablished. As mentioned above, the determination illustrated inoperation 206 can include evaluating the name specified in the queryreceived in operation 204 to determine if the specified name correspondsto a registered application 118. In some embodiments, the name specifiedin the query corresponds to an active name associated with a registeredapplication 118. In these and other circumstances, the client computer102 can determine that the trust relationship is to be established,though this is not necessarily the case. In some other embodiments, thename specified in the query corresponds to an inactive or unrecognizedname. In these and other circumstances, the client computer 102 candetermine that the trust relationship is not to be established, thoughthis is not necessarily the case.

If the client computer 102 determines, in operation 206, that the trustrelationship is to be established, the method 200 proceeds to operation208. In operation 208, the client computer 102 can issue a token to therequestor. The token issued in operation 208 can be used by therequestor to authenticate with the targeted application and/or otherwiseto communicate with the targeted application via a trusted connection.Thus, the requestor can use the token to establish and/or leverage atrust relationship between the requestor and the target application, forexample, to obtain configurations, to obtain settings, to share otherinformation, or the like.

If the client computer 102 determines, in operation 206, that the trustrelationship is not to be established, the method 200 proceeds tooperation 210. At operation 210, the client computer 102 can issue anerror or action code. It should be understood that the error or actioncode issued in operation 210 also can be obtained from the trust service110. As such, operation 210 can include receiving an error or actioncode as well as providing the error or action code to one or more of therequestor or the target application. Some illustrative error and/oraction codes are described below with reference to FIGS. 3-4.

From operation 208, the method 200 proceeds to operation 212. The method200 also can proceed to operation 212 from operation 210. It should beunderstood, however, that in some embodiments execution of the method200 ends after operation 210, though this embodiment is not illustratedin FIG. 2. In operation 212, the client computer 102 receives anapplication access request from an application 118 such as, for example,the requestor. It should be understood that the access request can occurat any time. Thus, execution of the method 200 can pause or beinterrupted at operation 212 unless and/or until an application accessrequest associated with the requestor is received. Because theapplication access request can occur immediately after operations 208 or210, it should be appreciated that a pause or interruption is notrequired in any of the described embodiments.

The application access request received in operation 212 can includeidentification of the requested application 118. Additionally, theapplication access request can include a token such as the token issuedin operation 208. From operation 212, the method 200 proceeds tooperation 214, wherein the client computer 102 can challenge therequestor and determine if the application access request is successful.Thus, the client computer 102 can examine the contents of theapplication access request received in operation 212 and determine ifaccess is to be granted or denied. In some embodiments, the clientcomputer 102 determines if a token is included in the application accessrequest, and if so, if the token is up-to-date, or the like.

If the client computer 102 determines, in operation 214 that the tokenis included in the application access request and/or that the token isvalid, the method 200 can proceed to operation 216. In operation 216,the client computer 102 can grant access to the application and/orinstruct the target application to communicate with the requestor. Asmentioned above, the access granted in operation 216 can relate toaccessing settings, configurations, data, and/or other informationassociated with the application 118B.

If the client computer 102 determines, in operation 214 that a token isnot included in the application access request and/or that the token isinvalid, the method 200 can proceed to operation 218. In operation 218,the client computer 102 can deny access to the application and/orinstruct the target application not to communicate with the requestor.Additionally, as mentioned above with regard to operation 210, theclient computer 102 can be configured to issue or instruct other nodesor devices to issue one or more error codes or action codes in responseto determining that access to the target application is to be denied.

From operation 216, the method 200 proceeds to operation 220. The method200 also can proceed to operation 220 from operation 218. The method 200ends at operation 220.

Turning now to FIG. 3, aspects of a method 300 for revoking and renewinga trust relationship between applications will be described in detail,according to an illustrative embodiment. The method 300 is described asbeing performed by the client computer 102. As explained above withreference to FIGS. 1-2, however, the functionality described herein withrespect to FIG. 3 can be provided by the trust service 110 instead of,or in conjunction with, the trust client 108 executed by the clientcomputer 102. As such, the described embodiment should be understood asbeing illustrative and should not be construed as being limiting in anyway.

The method 300 begins at operation 302, wherein the client computer 102establishes a trust relationship between two or more applications 118.It should be understood that the functionality of the client computer102 with respect to operation 302 can correspond to the functionality ofthe client computer 102 described above with reference to operations 208of the method 200 illustrated in FIG. 2. Because trust relationships canbe established in other ways, it should be understood that thisembodiment is illustrative, and should not be construed as beinglimiting in any way.

From operation 302, the method 300 proceeds to operation 304, whereinthe client computer 102 determines that a new token is available. Forexample, the client computer 102 can receive an action code or errorcode that specifies that a new token is available and/or that theexisting token is to be revoked. The error code or action code can beissued, for example, in operations 210 or 218 of the method 200described above. Because the client computer 102 can determine that anew token is available and/or that an old token is to be revoked in anumber of ways, it should be understood that these embodiments areillustrative, and should not be construed as being limiting in any way.

From operation 304, the method 300 proceeds to operation 306, whereinthe client computer 102 can revoke the old token. As such, the clientcomputer 102 can communicate with the target application and/or therequestor to indicate that the token possessed by the requestor has beenrevoked. As such, operation 306 can include instructing the targetapplication not to accept the old token. It should be understood thatthis embodiment is illustrative, and should not be construed as beinglimiting in any way.

From operation 306, the method 300 proceeds to operation 308, whereinthe client computer 102 can reestablish the trust relationship with thenew token. It should be understood that the functionality of the clientcomputer 102 for reestablishing the trust relationship in operation 308can be similar or even identical to the functionality of the clientcomputer 102 described above with reference to FIG. 2.

From operation 308, the method 300 proceeds to operation 310. The method300 ends at operation 310. It can be appreciated from FIG. 3 that theclient computer 102 can be configured to ensure that a trustrelationship between applications 118 is kept current and/or that sharedtokens can be revoked or updated periodically to prevent inadvertentdisclosure and/or use by unauthorized entities. According to variousembodiments, the client computer 102 can be configured not to storetokens or private keys. As such, the illustrated embodiments should beunderstood as being illustrative and should not be construed as beinglimiting in any way.

Turning now to FIG. 4, aspects of a method 400 for renewing a trustrelationship between applications 118 will be described in detail,according to an illustrative embodiment. The method 400 is described asbeing performed by the client computer 102. As explained above withreference to FIG. 3, however, the functionality described herein withrespect to FIG. 4 can be provided by the trust service 110 instead of,or in conjunction with, the trust client 108 executed by the clientcomputer 102. As such, the described embodiment should be understood asbeing illustrative and should not be construed as being limiting in anyway.

The method 400 begins at operation 402, wherein the client computer 102establishes a trust relationship between two or more applications 118.It should be understood that the functionality of the client computer102 with respect to operation 402 can be, but is not necessarily,similar or even identical to the functionality of the client computer102 described above with reference to operations 208 of the method 200illustrated in FIG. 2.

From operation 402, the method 400 proceeds to operation 404, whereinthe client computer 102 determines that the token used by theapplications 118 has timed out. In some embodiments, for example, theclient computer 102 can be configured to establish a lifetime orpersistence period for tokens issued by the client computer 102. Thus,the client computer 102 can determine, in operation 404, that thelifetime or persistence period has ended or otherwise terminated. Such adetermination can be completed by the client computer 102 by comparing apresent time with a determined termination or lapse time specified whenissuing or receiving the token, by expiration of a countdown timer, byreceiving notice that the token has expired, combinations thereof, orthe like. Because the client computer can be configured to determinethat the token has timed out in a number of ways, it should beunderstood that these embodiments are illustrative, and should not beconstrued as being limiting in any way.

From operation 404, the method 400 proceeds to operation 406, whereinthe client computer 102 can reestablish the trust relationship with anew token. It should be understood that the functionality of the clientcomputer 102 for reestablishing the trust relationship in operation 406can be similar or even identical to the functionality of the clientcomputer 102 described above with reference to FIG. 2. From operation406, the method 400 proceeds to operation 408. The method 400 ends atoperation 408.

It can be appreciated from FIG. 4 that the client computer 102 can beconfigured to ensure that a trust relationship between applications 118is kept current and/or that tokens are updated periodically atpredetermined intervals. Thus, the concepts and technologies disclosedherein can be used to help prevent inadvertent disclosure and/or use ofsecure application data by unauthorized entities. The illustratedembodiments should be understood as being illustrative and should not beconstrued as being limiting in any way.

As explained above with reference to various FIGURES, the trust client108, the trust service 110, and/or various devices executing the trustclient 108 and/or the trust service 110 can be configured to issue oneor more action codes or error codes. Some contemplated error codes,action codes, and their respective implications are set forth below inTABLE 1. These and other action codes or error codes can be used toestablish and/or manage trust relationships as described herein indetail.

TABLE 1 Error Code Meaning Action AC_Register_Key Register this keyRegister this public key with this name with this name. EC_Not_FoundThis name is not Do not register this found in the data name AC_RevokedThis name has been If this name was revoked registered, revoke all trustrelationship associated with this name AC_New_Version_Required This nameis Do not revoke old trust obsolete, a new relationships associated nameis required with old name. Tell this named application to update. Thisallows applications submitted requests with the old name to obtainaccess until updated. The update process can be used to clean up oldregistrations. AC_Destroy_Now This name is to be Tell the nameddestroyed now application to destroy itself now. EC_Suspended This namedPut this application in application has suspended status. No beensuspended trust relationship can be established when the application issuspended. This Error code also can dictate further action, such asrevoking all active tokens associated with this named application.AC_Set_Active If this named Whatever state this application wasapplication was in, set suspended before, this state as active now. setit as active Register this key (value of status response).AC_Try_Again_Later This action cannot Query with the same be completednow. query again X minutes Try again later. later as specified in thevalue of the status response, wherein X can be specified by usersettings or options. AC_Self_Destruct The trust service Revoke all trusttokens. and/or the trust Wipe client database or client have been otherdevice storing the compromised. data. Enter self-destruct Revoke alltokens mode (do not respond to and delete all data. any query, do notquery server, lock database). This only destroys the Trust Center.AC_Self_Upgrade The trust client Upgrade the trust client must beupgraded now. Upgrade does not affect existing trust relationships.EC_Challenge_Z Challenge the Use this value to requestor with thischallenge the requestor Z value EC_Challenge_Response Comparison of PValue 1 = matched. from the trust Value 0 = not matched. client, and Pcalculated on the trust server EC_Request_Complete_Successfully Requestcomplete Non-zero result code successfully. The determines the action tovalue carries the take. result of the query, if applicableEC_Request_Complete_with_Error Request complete Error result determineswith error. The the action to take. value carries the error resultEC_Cannot_Perform_Request Request cannot be Error code determinescomplete due to an the action to take. error. Error code has the detailsAC_Processing_Wait The trust client is Set the timer to wait forprocessing this the following response. request. Wait this When timerexpires, re- long before time- send the request. The out entity sendingthis status also runs a timer that will abandon this request when thetimer expires. AC_Revoke_Token Mark this token as Requestor using thisrevoked revoked token must not be allowed to use the service.AC_Remove_Token Remove this token Erase/delete/remove from list thistoken from a tokens list AC_Set_Token Set or add token to Set or addtoken to tokens list tokens list

Turning now to FIG. 5, additional details of the network 104 areillustrated, according to an illustrative embodiment. The network 104includes a cellular network 502, a packet data network 504, for example,the Internet, and a circuit switched network 506, for example, apublicly switched telephone network (“PSTN”). The cellular network 502includes various components such as, but not limited to, basetransceiver stations (“BTSs”), Node-B's or e-Node-B's, base stationcontrollers (“BSCs”), radio network controllers (“RNCs”), mobileswitching centers (“MSCs”), mobile management entities (“MMEs”), shortmessage service centers (“SMSCs”), multimedia messaging service centers(“MMSCs”), home location registers (“HLRs”), home subscriber servers(“HSSs”), visitor location registers (“VLRs”), charging platforms,billing platforms, voicemail platforms, GPRS core network components,location service nodes, an IP Multimedia Subsystem (“IMS”), and thelike. The cellular network 502 also includes radios and nodes forreceiving and transmitting voice, data, and combinations thereof to andfrom radio transceivers, networks, the packet data network 504, and thecircuit switched network 506.

A mobile communications device 508, such as, for example, a cellulartelephone, a user equipment, a mobile terminal, a PDA, a laptopcomputer, a handheld computer, and combinations thereof, can beoperatively connected to the cellular network 502. The cellular network502 can be configured as a 2G GSM network and can provide datacommunications via GPRS and/or EDGE. Additionally, or alternatively, thecellular network 502 can be configured as a 3G UMTS network and canprovide data communications via the HSPA protocol family, for example,HSDPA, EUL (also referred to as HSUPA), and HSPA+. The cellular network502 also is compatible with 4G mobile communications standards as wellas evolved and future mobile standards.

The packet data network 504 includes various devices, for example,servers, computers, databases, and other devices in communication withone another, as is generally known. The packet data network 504 devicesare accessible via one or more network links. The servers often storevarious files that are provided to a requesting device such as, forexample, a computer, a terminal, a smartphone, or the like. Typically,the requesting device includes software (a “browser”) for executing aweb page in a format readable by the browser or other software. Otherfiles and/or data may be accessible via “links” in the retrieved files,as is generally known. In some embodiments, the packet data network 504includes or is in communication with the Internet. The circuit switchednetwork 506 includes various hardware and software for providing circuitswitched communications. The circuit switched network 506 may include,or may be, what is often referred to as a plain old telephone system(POTS). The functionality of a circuit switched network 506 or othercircuit-switched network are generally known and will not be describedherein in detail.

The illustrated cellular network 502 is shown in communication with thepacket data network 504 and a circuit switched network 506, though itshould be appreciated that this is not necessarily the case. One or moreInternet-capable devices 510, for example, a PC, a laptop, a portabledevice, or another suitable device, can communicate with one or morecellular networks 502, and devices connected thereto, through the packetdata network 504. It also should be appreciated that theInternet-capable device 510 can communicate with the packet data network504 through the circuit switched network 506, the cellular network 502,and/or via other networks (not illustrated).

As illustrated, a communications device 512, for example, a telephone,facsimile machine, modem, computer, or the like, can be in communicationwith the circuit switched network 506, and therethrough to the packetdata network 504 and/or the cellular network 502. It should beappreciated that the communications device 512 can be anInternet-capable device, and can be substantially similar to theInternet-capable device 510. In the specification, the network 104 isused to refer broadly to any combination of the networks 502, 504, 506.It should be appreciated that substantially all of the functionalitydescribed with reference to the network 104 can be performed by thecellular network 502, the packet data network 504, and/or the circuitswitched network 506, alone or in combination with other networks,network elements, and the like.

According to various implementations of the concepts and technologiesdisclosed herein, the client computer 102 and/or the server computer 112can communicate with any combination of the devices disclosed hereinincluding, but not limited to, the mobile communications device 508, theInternet-capable device 510, and/or the communications device 512 togenerate queries, to generate responses, to generate and/or save publickeys or tokens, and/or to issue error codes, action codes, and/or otherinstructions. As such, it should be understood that the client computer102 and the server computer 112 can interact with one another and/or theapplication servers 116 via any number and/or combination of devices andnetworks.

FIG. 6 is a block diagram illustrating a computer system 600 configuredto provide the functionality described herein for a verificationservice, in accordance with various embodiments of the concepts andtechnologies disclosed herein. The computer system 600 includes aprocessing unit 602, a memory 604, one or more user interface devices606, one or more input/output (“I/O”) devices 608, and one or morenetwork devices 610, each of which is operatively connected to a systembus 612. The bus 612 enables bi-directional communication between theprocessing unit 602, the memory 604, the user interface devices 606, theI/O devices 608, and the network devices 610.

The processing unit 602 may be a standard central processor thatperforms arithmetic and logical operations, a more specific purposeprogrammable logic controller (“PLC”), a programmable gate array, orother type of processor known to those skilled in the art and suitablefor controlling the operation of the server computer. Processing unitsare generally known, and therefore are not described in further detailherein.

The memory 604 communicates with the processing unit 602 via the systembus 612. In some embodiments, the memory 604 is operatively connected toa memory controller (not shown) that enables communication with theprocessing unit 602 via the system bus 612. The memory 604 includes anoperating system 614 and one or more program modules 616. The operatingsystem 614 can include, but is not limited to, members of the WINDOWS,WINDOWS CE, and/or WINDOWS MOBILE families of operating systems fromMICROSOFT CORPORATION, the LINUX family of operating systems, theSYMBIAN family of operating systems from SYMBIAN LIMITED, the BREWfamily of operating systems from QUALCOMM CORPORATION, the MAC OS, iOS,and/or LEOPARD families of operating systems from APPLE CORPORATION, theFREEBSD family of operating systems, the SOLARIS family of operatingsystems from ORACLE CORPORATION, other operating systems, and the like.

The program modules 616 may include various software and/or programmodules described herein. In some embodiments, for example, the programmodules 616 include the trust client 108 and/or the trust service 110.This and/or other programs can be embodied in computer-readable mediacontaining instructions that, when executed by the processing unit 602,perform one or more of the methods 200, 300, 400 described in detailabove with respect to FIGS. 2-4. According to embodiments, the programmodules 616 may be embodied in hardware, software, firmware, or anycombination thereof. Although not shown in FIG. 6, it should beunderstood that the memory 604 also can be configured to store the data114 and/or other information, if desired.

By way of example, and not limitation, computer-readable media mayinclude any available computer storage media or communication media thatcan be accessed by the computer system 600. Communication media includescomputer-readable instructions, data structures, program modules, orother data in a modulated data signal such as a carrier wave or othertransport mechanism and includes any delivery media. The term “modulateddata signal” means a signal that has one or more of its characteristicschanged or set in a manner as to encode information in the signal. Byway of example, and not limitation, communication media includes wiredmedia such as a wired network or direct-wired connection, and wirelessmedia such as acoustic, RF, infrared and other wireless media.Combinations of the any of the above should also be included within thescope of computer-readable media.

Computer storage media includes volatile and non-volatile, removable andnon-removable media implemented in any method or technology for storageof information such as computer-readable instructions, data structures,program modules, or other data. Computer storage media includes, but isnot limited to, RAM, ROM, Erasable Programmable ROM (“EPROM”),Electrically Erasable Programmable ROM (“EEPROM”), flash memory or othersolid state memory technology, CD-ROM, digital versatile disks (“DVD”),or other optical storage, magnetic cassettes, magnetic tape, magneticdisk storage or other magnetic storage devices, or any other mediumwhich can be used to store the desired information and which can beaccessed by the computer system 600. In the claims, the phrase “computerstorage medium” and variations thereof, does not include waves, signals,and/or other transitory and/or intangible communication media, per se.

The user interface devices 606 may include one or more devices withwhich a user accesses the computer system 600. The user interfacedevices 606 may include, but are not limited to, computers, servers,personal digital assistants, cellular phones, or any suitable computingdevices. The I/O devices 608 enable a user to interface with the programmodules 616. In one embodiment, the I/O devices 608 are operativelyconnected to an I/O controller (not shown) that enables communicationwith the processing unit 602 via the system bus 612. The I/O devices 608may include one or more input devices, such as, but not limited to, akeyboard, a mouse, or an electronic stylus. Further, the I/O devices 608may include one or more output devices, such as, but not limited to, adisplay screen or a printer.

The network devices 610 enable the computer system 600 to communicatewith other networks or remote systems via a network, such as the network104. Examples of the network devices 610 include, but are not limitedto, a modem, a radio frequency (“RF”) or infrared (“IR”) transceiver, atelephonic interface, a bridge, a router, or a network card. The network104 may include a wireless network such as, but not limited to, aWireless Local Area Network (“WLAN”) such as a WI-FI network, a WirelessWide Area Network (“WWAN”), a Wireless Personal Area Network (“WPAN”)such as BLUETOOTH, a Wireless Metropolitan Area Network (“WMAN”) such aWiMAX network, or a cellular network. Alternatively, the network 104 maybe a wired network such as, but not limited to, a Wide Area Network(“WAN”) such as the Internet, a Local Area Network (“LAN”) such as theEthernet, a wired Personal Area Network (“PAN”), or a wired MetropolitanArea Network (“MAN”).

Based on the foregoing, it should be appreciated that systems andmethods for a peer applications trust center have been disclosed herein.Although the subject matter presented herein has been described inlanguage specific to computer structural features, methodological andtransformative acts, specific computing machinery, and computer-readablemedia, it is to be understood that the invention defined in the appendedclaims is not necessarily limited to the specific features, acts, ormedia described herein. Rather, the specific features, acts and mediumsare disclosed as example forms of implementing the claims.

The subject matter described above is provided by way of illustrationonly and should not be construed as limiting. Various modifications andchanges may be made to the subject matter described herein withoutfollowing the example embodiments and applications illustrated anddescribed, and without departing from the true spirit and scope of theembodiments, which is set forth in the following claims.

I claim:
 1. A method comprising: registering, at a device comprising ahardware processor that executes a first application, a secondapplication and a third application, wherein registering the thirdapplication comprises obtaining a unique identifier associated with thethird application; receiving, by the device, a request to establish atrust relationship between the second application and the thirdapplication, the request being received from the second application; inresponse to determining, that the trust relationship is authorized,issuing, by the device, a token to the second application; receiving, bythe device and from the second application, an application accessrequest comprising the unique identifier and the token, wherein thedevice identifies the third application based upon the unique identifierand determines if access to the third application is to be granted tothe second application based on the token; and establishing, by thedevice, the trust relationship between the third application and thesecond application, whereby the third application is granted access tothe second application.
 2. The method of claim 1, wherein determining ifthe access is to be granted comprises determining if the token is valid.3. The method of claim 1, wherein the unique identifier comprises apublic key.
 4. The method of claim 1, wherein obtaining the uniqueidentifier comprises obtaining a first public key that is associatedwith the second application and obtaining a second public key that isassociated with the third application, and wherein the unique identifiercomprises the second public key.
 5. The method of claim 1, whereindetermining if the access is to be granted comprises determining if thetoken is valid, and wherein the device is configured to issue an errorcode to the second application and to deny the access in response to adetermination that the token is not valid.
 6. The method of claim 1,wherein determining that the trust relationship is authorized comprises:determining that the unique identifier corresponds to the thirdapplication; and determining that the third application comprises aregistered application.
 7. The method of claim 1, wherein issuing thetoken comprises: determining a time period for which the token will bevalid; and issuing the token with a life that corresponds to the timeperiod determined.
 8. The method of claim 7, further comprising:determining that the token has expired; issuing a new token; andreestablishing the trust relationship using the new token.
 9. The methodof claim 1, further comprising: determining that a new version of thetoken is available; revoking the token; issuing the new version of thetoken; and reestablishing the trust relationship using the new versionof the token.
 10. The method of claim 1, wherein the second applicationauthenticates with the third application using the token.
 11. A systemcomprising: a processor; and a memory that stores a first applicationcomprising computer-executable instructions that, when executed by theprocessor, cause the processor to perform operations comprising:registering a second application and a third application, whereinregistering the third application comprises obtaining a uniqueidentifier associated with the third application, receiving a request toestablish a trust relationship between the second application and thethird application, the request being received from the thirdapplication, in response to determining that the trust relationship isauthorized, issuing a token to the third application, receiving, fromthe third application, an application access request comprising theunique identifier and the token, wherein the processor identifies thesecond application based upon the unique identifier and determines ifaccess to the third application is to be granted to the secondapplication based on the token, and establishing the trust relationshipbetween the second application and the third application whereby thesecond application is granted access to the third application.
 12. Thesystem of claim 11, wherein determining if the access is to be grantedcomprises determining if the token is valid, and wherein if adetermination is made that the token is not valid, an error code isissued to the second application and access to the third application isdenied.
 13. The system of claim 11, wherein the request to establish thetrust relationship comprises a name identifying an application, andwherein determining that the trust relationship is authorized comprisesdetermining that the name corresponds to the second application anddetermining that the second application comprises a registeredapplication.
 14. The system of claim 11, wherein the computer-executableinstructions, when executed by the processor, cause the processor toperform operations further comprising: determining a time period forwhich the token will be valid; specifying a life of the token, the lifeof the token corresponding to the time period; issuing the token withthe life specified; determining that the token has expired; issuing anew token; and reestablishing the trust relationship using the newtoken.
 15. The system of claim 11, wherein the computer-executableinstructions, when executed by the processor, cause the processor toperform operations further comprising: determining that a new version ofthe token is available; revoking the token; issuing the new version ofthe token; and reestablishing the trust relationship using the newversion of the token.
 16. A computer storage medium havingcomputer-executable instructions stored thereon that, when executed by aprocessor, cause the processor to execute operations associated with afirst application, the operations comprising: registering a secondapplication and a third application, wherein registering the thirdapplication comprises obtaining a unique identifier associated with thethird application; receiving a request to establish a trust relationshipbetween the second application and the third application, the requestbeing received from the third application; in response to determiningthat the trust relationship is authorized, issuing a token to the thirdapplication; receiving, from the third application, an applicationaccess request comprising the unique identifier and the token, whereinthe processor identifies the second application based upon the uniqueidentifier and determines if access to the third application is to begranted to the second application based on the token; and establishingthe trust relationship between the second application and the thirdapplication whereby the second application is granted access to thethird application.
 17. The computer storage medium of claim 16, whereindetermining if the access is to be granted comprises determining if thetoken is valid, and wherein if a determination is made that the token isnot valid, an error code is issued to the second application and accessto the third application is denied.
 18. The computer storage medium ofclaim 16, wherein the computer-executable instructions, when executed bythe processor, cause the processor to perform operations furthercomprising: determining that a new version of the token is available;revoking the token; issuing the new version of the token; andreestablishing the trust relationship using the new version of thetoken.
 19. The computer storage medium of claim 16, wherein the requestto establish the trust relationship comprises a name identifying anapplication, and wherein determining that the trust relationship isauthorized comprises determining that the name corresponds to the secondapplication and determining that the second application comprises aregistered application.
 20. The computer storage medium of claim 16,wherein the computer-executable instructions, when executed by theprocessor, cause the processor to perform operations further comprising:determining a time period for which the token will be valid; specifyinga life of the token, the life of the token corresponding to the timeperiod; issuing the token with the life specified; determining that thetoken has expired; issuing a new token; and reestablishing the trustrelationship using the new token.